FOG Computer Cloning Solutions with ERPXE
ERPXE is an open source PXE project that unites recovery tools and operating system installers in a single network boot environment. For teams that depend on network-based imaging, FOG is a widely used computer cloning solution that can work alongside a PXE setup. This page covers how FOG-style cloning fits an ERPXE workflow, what to prepare before deployment, and how to keep imaging dependable across your network.
Understanding FOG Cloning in a PXE Environment
FOG is a free, open source solution for computer cloning and imaging. In practice, it lets you capture a reference machine as an image and push that image to other machines over the network. Since both FOG and ERPXE rely on PXE booting, they handle the same early phase of a machine's lifecycle: getting a client to boot from the network before an operating system is installed or repaired.
ERPXE concentrates on delivering a wide range of recovery tools and OS installers over PXE. FOG concentrates on capturing, storing, and distributing disk images. Combined, they can support both ad-hoc recovery and repeatable mass deployment. The exact integration depends on your network design, so treat the guidance below as a starting framework rather than a fixed recipe.
Planning Your Cloning Workflow
Before adding cloning to an ERPXE environment, decide how the two services will share the network. A few practical points to consider:
- Boot server roles: Decide whether ERPXE and your cloning service will share a PXE boot server or run on separate hosts. Separate hosts are often easier to troubleshoot.
- DHCP and boot options: PXE clients need clear instructions about which boot file to request. If you run more than one PXE service, scope or filter DHCP options so each client reaches the intended menu.
- Storage: Disk images are large. Plan storage capacity and throughput for the cloning server before you capture your first image.
- Network throughput: Multicast or unicast deployment performance depends on switch configuration and link speeds. Identify bottlenecks before a large rollout.
- Client compatibility: Confirm that target hardware supports network boot and that its firmware is configured to allow it.
Preparing Clients and Images
A cloning project succeeds or fails on preparation. Begin with a clean reference machine: install the operating system, apply updates, and configure the software baseline you intend to standardize. Keep drivers in mind, especially if your fleet includes more than one hardware model.
When you capture an image, document what it contains and when it was created. A simple naming convention and a short changelog save hours later. Test each image on a small number of machines before scheduling a wider deployment, and verify that the deployed system boots correctly and retains the settings you expect.
If you use ERPXE to deliver recovery or installation tools alongside cloning, make sure the boot menus are clearly labeled so technicians choose the right entry under pressure.
Troubleshooting Common Cloning Issues
Most cloning problems fall into a few categories. Work through them systematically:
- Client does not PXE boot: Check firmware boot order, network cable, and DHCP scope options. Confirm the client is reaching the intended boot server.
- Boot menu appears but the wrong entry loads: Review menu configuration and any DHCP filters that direct clients to different services.
- Image deployment is slow: Look at switch link speeds, duplex settings, and whether multicast is configured correctly for your topology.
- Deployed machine fails to boot: Verify the image matches the target hardware, particularly storage controller and boot mode (legacy versus UEFI).
- Inconsistent results across machines: Standardize firmware settings and confirm that all targets use the same boot mode and disk layout.
Keep logs from both the PXE environment and the cloning service. Correlating the two timelines usually reveals where a deployment stalled.
Where to Go Next
ERPXE's installation guide, plugins information, and troubleshooting pages cover the PXE side of the equation. For cloning-specific configuration, consult the FOG project's own documentation and community. The ERPXE community forum is a good place to ask how others have combined PXE tooling with imaging workflows in their environments.
Frequently Asked Questions
Is FOG part of ERPXE?
No. FOG is a separate open source cloning solution. ERPXE is an open source PXE project. They can be used alongside each other because both rely on network booting, but they are distinct projects with their own documentation and support channels.
Can I run ERPXE and a cloning server on the same network?
Yes, but plan the DHCP and boot configuration carefully. Many administrators prefer to keep PXE services on separate hosts or use DHCP scopes and filters to route clients to the correct boot server.
Do I need special hardware for network cloning?
Clients need network boot capability in their firmware, and the cloning server needs adequate storage and network throughput for the images you plan to store and deploy. Requirements scale with the size of your fleet and images.
How do I choose between unicast and multicast deployment?
Multicast can reduce network load when deploying the same image to many machines at once, but it depends on switch support and configuration. Unicast is simpler and often sufficient for smaller batches. Test both in your environment.
Where can I get help?
Use the ERPXE community forum for PXE-related questions and the FOG project's documentation and community for cloning-specific issues. Include logs and configuration details when asking for help.
Whether you are setting up a first PXE lab or expanding an existing deployment, the key is to keep boot services and imaging services clearly separated and well documented. Label your boot menus, record image contents, and test changes on a small group of clients before rolling them out. That discipline makes it easier to combine ERPXE recovery tools with FOG-style cloning without surprises.
